Internet Protocol security (“IPSec”) is a set of protocols developed by the Internet Engineering Task Force (IETF) to support secure exchange of Internet Protocol (“IP”) packets among hosts in a network. IPSec provides security for transmission of sensitive information over open networks such as the Internet and may be implemented in the form of IPSec agents within the operating system of hosts in the network. IPSec acts at the network layer to protect and authenticate IP packets between participating IPSec devices.
Under IPSec, a “secure tunnel” is created when IPSec is used among hosts at separate points in a network for hiding an IP packet, by encapsulating the packet in an IPSec packet with new IP header values. The participating IPSec devices at either end of a secure tunnel are termed “IPSec peers.” The IPSec peer that seeks to send an IP packet on behalf of a source end host through a secure tunnel is termed an “initiator peer.” The IPSec peer that receives the IP packet on behalf of a destination end host is termed a “responder peer.”
FIG. 1 is a block diagram that illustrates a simplified network topology between two end hosts. In FIG. 1, source end host 102 is communicatively coupled to initiator peer 104. Initiator peer 104 is communicatively coupled to responder peer 106. Responder peer 106 is in turn communicatively coupled to destination end host 108. In certain embodiments of the invention, the source end host and the initiator peer may be one device, such as a router or switch executing an IPSec agent. Similarly, the destination end host and the responder peer may be one device.
In operation, source end host 102 generates an IP packet P that is destined for destination end host 108. Initiator peer 104 may be implemented as a router with an encrypting interface on the router's outbound interface. Initiator peer 104 is configured to encrypt IP traffic from subnet W.W.W.W, which includes source end host 102, to subnet X.X.X.X, which includes destination end host 108. Thus, initiator peer 104 protects the proxies (W.W.W.W, X.X.X.X), termed the “initiator peer's full proxy.” W.W.W.W alone and X.X.X.X alone each are termed an “initiator peer's half proxy.” Subnets W.W.W.W and X.X.X.X may include protocol and port information.
Responder peer 106 is configured to encrypt IP traffic from subnet Y.Y.Y.Y, which includes destination end host 108, to subnet Z.Z.Z.Z, which includes source end host 102. Thus, responder peer 106 protects the proxies (Y.Y.Y.Y, Z.Z.Z.Z), referred to as the “responder peer's full proxy.” Y.Y.Y.Y alone and Z.Z.Z.Z alone are each referred to as the “responder peer's half proxy.”
The IPSec participating peers between which a secure tunnel is to be established generally need to dynamically determine each other's identity. The IPSec peers associated with the secure tunnel need to know of each other's identity in order to negotiate proxies.
In one approach to determine identity, a dynamic crypto map is defined for responder peers to determine IPSec peers. In another approach, a tunnel endpoint discovery mechanism is used by the initiator peer to dynamically determine an IPSec peer. The responder peer and the initiator peer are each configured with a security policy. The responder peer is not aware of the contents of the initiator peer's security policy, nor does the initiator peer know the contents of the responder peer's security policy. Therefore, a first peer cannot determine if it is permitted to establish a secure tunnel with a second peer based solely on the identity of the second peer.
Referring again to FIG. 1, in order to establish a secure tunnel between source end host 102 and destination end host 108 using IPSec, initiator peer 104 creates a proposal of the types of packets that are to be protected by the secure tunnel that is to be established. A description of the types of packets that will be protected by the secure tunnel is herein referred to as a “proxy.” Initiator peer 104 sends the proposal of the types of packets—that is, a proposed set of proxies—to responder peer 106. When responder peer 106 receives the proposed set of proxies, responder peer 106 checks the proposed set of proxies against responder peer's security policy. If the proposed set of proxies does not match responder peer's security policy, then responder peer 106 will refuse to establish the secure tunnel between initiator peer 104 and responder peer 106.
In one approach, initiator peer 104 sends to responder peer 106 the half proxy W.W.W.W, which includes source end host 102. If the half proxy W.W.W.W matches responder peer's security policy, then responder peer 106 sends the responder peer's half proxy Z.Z.Z.Z, which also includes the source end host. Initiator peer 104 then merges the two half proxies in an attempt to obtain a set of proxies, herein referred to as “merged proxies,” which is mutually acceptable to both the initiator peer and responder peer. This approach is represented by the Tunnel Endpoint Detection (TED) protocol, versions 1 and 2, as implemented in certain products of Cisco Systems, Inc.
A drawback to this approach is that the merged proxies do not work in all circumstances. For example, the merged proxies (W.W.W.W, Z.Z.Z.Z) will not be acceptable to the responder peer if the responder peer's security policy requires the merged proxies to satisfy responder peer's other half proxy Y.Y.Y.Y.
Moreover, such an approach does not specify the specific transport level protocol that is needed for the network traffic through the secure tunnel, such as TCP, UDP, etc.
Thus, one of the difficulties with deploying ISAKMP/IPSec-based networks is configuring each IPSec host or security gateway with the information required to associate what encrypted traffic should be forwarded to which peer, and which are the necessary proxies that should be used to define what traffic should be protected. The TED approach has been usable only where the initiator could specify the source IP address, and the responder could specify the destination IP address.
Based on the foregoing, there is a clear need for a way to provide for negotiating proxies that are mutually acceptable to the initiator peer and the responder peer under all circumstances.